Search

This is what we called "Scrum But".

不要...

  • Share this:

This is what we called "Scrum But".

不要再請鬼抓藥單了,要不要找一下我們這種專業人士去啊?

感覺就像寧可相信電台賣藥的,不相信醫生的建議,自己覺得醫生講的我也會,我也可以致病。

背後的科學基礎、整體系統全貌、累積夠多的失敗與順利上軌道的實務經驗,才是專業人士提供服務的依據。

就像你也知道投三分球得到的分數比較高,Curry 可以從三分線到半場都是他的開火距離,但你學得起來嗎?那適合你嗎?照著你只看到的表面模樣去依樣畫葫蘆,其實還蠻容易死人的,最後就會造就一堆不明究理的人上來靠北工程師上浪費生命。

至少先問一下,你們大家覺得 daily scrum 是為了什麼(我不是問 how,我是問 why),每一個設計的環節都有背後要解決的問題,而這些設計的環節可以彼此搭配出一些綜效。

如果你知道每一個設計環節的目的,要解決的問題,適用場景與限制,那你只要知道現在的團隊、組織痛點在哪、瓶頸點在哪、限制在哪,你就可以比較容易找到突破點,先讓大家進入改善的起點,有感之後,消除瓶頸就會引發瓶頸點轉移,一路把瓶頸點進行改善,就會發現整個 scrum 該有的,大概都有了。

如果你知道全貌,包含背後的目的,理論的基礎,實務的手法,甚至知道其他更多可以解決相同問題但不包含在 scrum 裡面的學問,你才能適時因人因地至宜。

很多人的邏輯沒學好,他們會說「這不是 scrum」,而忽略了「scrum framework 只是指出你該有哪些東西」,它只希望是個 framework,不要給你太多的「限制」,但你不能偏離它的核心與價值觀。

也就是 scrum 上沒有的,不代表你不能做,不是「這不是 scrum」,而是「scrum 沒有規定不能做」。

當然,scrum but 還是很有參考價值的,因為那幾乎都是「錯」的 pattern。

我一般都是建議入門者去看 scrum guide 跟 scrum master checklist (檢查一下你們在各個角色,有沒有符合上面的特徵跟選項),如果看不出來為啥那是個問題,那不知道這是問題就是個大問題。

#有用的話三萬塊不嫌貴
#沒用的話30塊還傷身體
#不要再請鬼抓藥單

--
另一個簡單的判斷標準,你就看你要找的對象,他平時呈現出來的言行是否一致,價值觀是否符合他老是掛在嘴巴上侃侃而談的東西。還是只是老是跩文的 buzzword guy,只是追逐著那堆潮流名詞只為了框點顧問費,是不是那種只是「人脈-driven」酬庸型的顧問。(我實在收別人的爛尾收到有點懶了)

認識我的朋友、參加培訓的學員、被我輔導過的團隊,常關注我 facebook 上分享的內容,應該都可以知道我是怎麼讓自己的人生、職涯、學習跟生活敏捷化的,對我們來說,了解了背後科學依據、理論基礎(scrum 背後的理論基礎跟科學依據,當然遠遠超過 scrum 的範圍,只學 scrum 當然只有皮),自然做事就會選擇有效果的方式。

再講一下 Odd-e 好了,大家 scrum 團隊成員太多,就會想拆 team 對吧?我們是公司超過5個人,基本上就會「拆另一間公司」出來,這樣公司層級的決策速度才會快,大家也才能都參與到。

我們所有的決定,都是團隊一起決定的,人數過多溝通成本過高,反應速度就會變慢。

我們所有的工作,都是自己決定的,薪水也是自己決定的,沒人會指派工作給你,你就是自己、產品、服務、公司的 owner。

註:我們公司的組織階層只有一層,我們的 founder,也是 LeSS 創始人之一的 Bas,跟所有 Odd-e 的人在同一層。扁平式組織?我們是一層式組織,這一層還可以圍成一個圈,互相支援所有事務。

我們講跨職能,Odd-e 的 never does 裡面在 Odd-e 公司內,是不招聘單一職能的夥伴的(例如行政、HR、法務、總務、會計,甚至只擔任講師,其他事情都不想管的那種),你就是公司,該了解的都得學會了解與負責,你才會當責、你才會有切膚之痛,你才會用心跟關心所有事情。這是我們的自組織 + ownership + end-to-end feature team。

我們講的 respect, open, 都能直接在 Odd-e never does 中窺探一二。我們不列所謂的「企業價值觀」,因為我們覺得通常列了什麼價值觀,就是缺了什麼。

我們只列出「我們共同認為不可以做、不該做的事情」,除此以外,是 open 的,你可以做任何事情,別人不能干涉你,當然團隊可以討論商量。

我們相信,每個人提出的觀點看法(perspective) 都有他的價值所在,當對方願意花時間講出來他的 perspective 跟你討論甚至爭論,都是值得被尊重的。我們也相信,任何事情都不會只有單一的 perspective。

如果身為 Odd-e 成員,還需要別人幫你安排好各種工作或事情,你才知道要做什麼,那你根本不該也不會被招進來當夥伴的。

當然,我們每個人還是有自己擅長、喜歡、不喜歡的事情和領域,但我們知道,這都不影響 ownership,該做的事情還是得有人做,但我們都知道也都具備「學習意願」,只要團隊或整個 Odd-e 有人對那一塊領域熟悉或擅長,我們就能跟他取經、抱大腿,或是請他幫忙。

我們對於自己開發產品或提供服務的要求(其實也不算是要求了,因為我們的人生就已經是敏捷化了),只會比客戶高,不會比客戶低。

所以啦,當你們想找外部教練來幫忙時,先去了解觀察探聽一下,他們公司是怎麼運作的,那個教練/顧問是個怎樣的人,是否言行合一,還是只是把「敏捷/scrum/lean」當作工作、商業上拿來賺錢的工具而已。

--
靠北工程師 原討論串 來源:https://www.facebook.com/init.kobeengineer/photos/a.1416496745064002/4100237950023188


Tags:

About author
我是 Joey Chen,闖蕩江湖的稱號是 91,熱血點火師,專門燃起大家心裡面的熱情與初衷。 目前為 Odd-e Taiwan 的負責人,同時也是 JetBrains 在台灣的培訓夥伴,至今也仍是熱愛學習與享受各種程式語言之美的 programmer。 身為敏捷教練,擅長 Agile、Scrum、LeSS 等敏捷文化與協作框架的落實與導入,如何讓大家 being agile 而不是 doing agile。同時喜歡結合各家所長,例如 Lean, Kanban 等,重點是持續改善、解決問題、端出成果,而不執著於某種特定方法論或框架。 身為技術教練,我也是極限編程(extreme programming)的狂熱者,我擅長用這些技術與工程實踐來提昇產品的品質、團隊的生產力、降低營運風險,因應市場與公司的商業目標,讓團隊能具有高適應與反應能力的基礎建設。例如 實例化需求、ATDD、BDD、TDD、重構、自動化單元測試/整合測試/驗收測試、CI/CD、code review、pair programming、mob-programming 等等。 同時,我也是推崇 極速開發 的 developer,追求從想法到產品程式碼的完成,中間的時間差能趨近於零,也就是劍隨心轉,想到哪,程式碼就長到哪的境界。從想法到實現中間的等待,其實在實務上佔了很大的 context switch 成本,如果能讓這段時間縮到最短,就能比其他人多嘗試更多種解決方案,進而挑選出最剛好的方案。 同時也是技術社群的活躍份子,從 2010 年開始連任九屆的微軟 MVP,兼任 MSDN 論壇板主,也曾經獲得年度 MSDN 文件庫刊登數量世界第一的榮耀。對微軟技術有愛,對 C# 有愛,對自動測試有愛,對重構與設計模式有愛。近年來對 Java, PHP, Python 也充滿濃厚的興趣,曾帶領客戶團隊中不會寫程式的 QA ,一起用 Python 完成超過百個 mobile UI 自動化測試。 擁有超過十年擔任開發團隊 tech leader, trainer, coach 與 mentor 的經驗,進行的企業內部與公開技術培訓課程已超過 100 場,培訓過的開發人員超過 1000 位,擔任研討會與社群活動的講師次數超過 30 次。 同時也是技術書籍的作者與譯者,與朋友合著的書籍包含《ASP.NET MVC 5:網站開發美學》、《ASP.NET MVC 4 網站開發美學》,翻譯的書籍有《單元測試的藝術-第二版》、《敏捷開發實踐》、《進入IT產業必讀的200個 .NET面試決勝題》。 如果想跟我即時互動,歡迎直接私訊或 email 至 [email protected]
請參考:https://tdd.best/about/
View all posts